IBIS Macromodel Task Group Meeting date: 27 June 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad: The meeting next week (July 4th) is cancelled. We will meet again in two weeks. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Bob M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 158.6: - Arpad: Radek has a new draft of BIRD 158.6 to discuss. - Radek: I would like to introduce it here, and then we can post it. - [sharing the new draft] - This incorporates comments from the discussions that started after Michael Mirmak's comments on 158.5. - We waited for BIRD 186 to be finalized so we could apply the same language related to file references. - "Step response" was not mentioned elsewhere in the spec, so we removed it. - Incorporated discussion related to how much the Ts4file describes (buffer, buffer plus on die, buffer plus on die plus package). - New Section: 10.x ALTERNATIVE AMI ANALOG BUFFER MODELING - Tx and Rx circuit diagrams unchanged, but their titles are changed. - Discussion of package: - Tx and Rx diagram indicate "buffer terminals". - The overall circuit diagram is consistent with that. It shows the "package" block in the user setup portion of the figure. - The following paragraph explains, "...package model is added to the channel by the user... In any case the package and possibly the on-die interconnect data associated with the IBIS Model...shall not be automatically incorporated into the above schematic by the EDA tool." - Arpad: I understand that what the Ts4file includes will be defined by Ts4file_Boundary. - But I was expecting that the package information provided by the IBIS file, particularly if it's BIRD 189, could be applied by the tool. - Is this BIRD saying the user will always have to add the package manually? - Radek: This language has to specify what the default intent is. - The intent is as described here, because if the EDA tool automatically includes something from the IBIS model then you may deprive the user of the chance to add their own separate package. - We do have cases where model makers distribute separate (external to IBIS) package model files. - It is still possible for the EDA tool to add the package information, if it first offers that choice to the user. - "...shall not be automatically..." - Automatically means without user interaction. - Michael M.: Does that mean we don't need to set a hierarchy assumption for traditional IBIS package vs. BIRD 189 [Interconnect Model Set Selector] vs. Ts4file_Boundary? - Radek: We don't specify that here. We leave the freedom to the user. - The EDA tool may find a way to free the user of having to manually add the package information, but we want the user to have the choice. - As default behavior we don't want the EDA tool automatically adding any package information without the user's input. - Walter: In our tool, we give the user options: no package at all, legacy RLC lumped, legacy [Package Model] (coupled matrix or path type), and we also have our own scheme similar to BIRD 189. - Whatever the user chooses, this 4-port gets hooked up to that. - This would be exactly the same if you replaced these Ts4files with [External Model]s. - Arpad: Should we have an optional parameter to specify whether a legacy IBIS package or BIRD 189 package should be used automatically, so the user doesn't have to do it manually all the time? - Walter: The tool could simply follow the Ts4file_Boundary parameter and decide what to include based on that. - Arpad: No, because what Radek is saying has merit. What if the IBIS [Model] just includes useless old RLC package values and the user wants to override that. Today the user might zero it out, or comment it out, and then place their own package model on the schematic. But that might require modifying the IBIS file. - Why can't we just have a parameter that does the same thing and gives the choice of using IBIS keywords or having the user do things manually. - Walter: That's not a boundary on the Ts4file, it's a [Model] boundary. - Arpad: Yes, it's a separate parameter. - Radek: That would be defining the boundary on the "User Setup" portion of the schematic diagram. - We could add a parameter like that and the EDA tool could choose to use it. - But Walter described a tool that already gives the user the choice, and that's a good way to do it. We just don't want the tool to put something in automatically and keep the user in the dark and end up double counting. - Walter: Since Ts4file_Boundary defaults to "pad", and since for legacy models pad = buffer, I think we are okay. - Since the legacy package model keywords hook up to the buffer, and the default of Ts4file_Boundary is legacy buffer, then you can just use whatever you are using today in IBIS to determine your package model. - Arpad: The current wording explicitly says the EDA tool should not do that. - Radek: The EDA tool should not do it automatically. - Walter: I'm fine with the current wording. I think it allows tools to give the user the choice of what to do. - Mike L.: What is the meaning when Ts4file_Boundary is "buffer". - [looking at the Rx diagram] - 2 and 4 are already at the buffer? - Radek: 2 and 4 are at the decision point. - Mike L.: I see, so if it's "buffer" then the Ts4file contains just the analog portion of the buffer (no on-die interconnect). - Radek: I will send this out. - I think we are fine with this language. We are not imposing any replacement of the package, it just has to be left to the user to choose. - Walter: Are we ready to recommend BIRD 158 to the Open Forum? - Arpad: I hate to delay another two weeks, but we should get it posted and give everyone a chance to carefully review it. - BIRD 190: - Ambrish: Motion to untable BIRD 190. - Radek: Second. [none opposed] - Ambrish: This was introduced and discussed at the Open Forum meeting along with a presentation from Walter. - Walter's objections were based on statistical flow. - BIRD 190 doesn't mention anything about statistical simulation. It's in the time domain section. - Therefore, I'd like to discuss it again. - The reasons are the same ones we brought forth when the BIRD was introduced. - This is a restatement of a warning from the single channel flow. - Walter: I object. I think BIRD 190 should not be considered until we fix the flow with BIRD 166 or Fangyi's proposal. - Ambrish pointed out that BIRD 190's comments are in the time domain section. - I think the flow is wrong in both statistical and time domains. - [sharing email exchange with Ambrish] - I agree it applies to time domain. - But if any of the models has GetWave_Exists = false, then the output of Rx AMI_Init() is used in time domain. - If all of the models are Init Only, then the output of Rx2's AMI_Init() is used for time domain simulations. - Opening sentence of BIRD 190 text: - "The Rx2 executable model file writer for the downstream channels with Redrivers..." - But the model maker may have no idea if there's a redriver or retimer in front of their model. - Normally the model maker creates it for a single channel, and if the channel gets too long, noisy, etc., the system designer might add in a redriver. - Bob M.: I would just note that some model makers probably know there will not be a redriver in front of them. For example, high performance ASIC channels where the use of a redriver is fundamentally impossible. - I mention this just in terms of the difference between a necessary condition or a sufficient condition for the warning prescribed in BIRD 190. - Walter: My experience with 802.3 channels is that a design starts without a redriver and then later it gets added. - [continuing review of BIRD 190] - The person designing the model already assumes the input to the model is valid. - The model maker already has to assume the IR input to Init() isn't complete. - So the model has to handle manual settings (optimization off), and that's true for a redriver or a normal channel case. - The time domain flow for redrivers just refers back to the single channel flow. That single channel flow already contains this warning paragraph. - Adding it here, the "does not include the effects..." is just repeating the fundamental problem for why 6.1 gives the wrong answer. - Ambrish: This is not about statistical analysis. - Walter: If all of the models are Init Only, the standard says to convolve the output of Rx2 Init() with the digital stimulus to Tx1. - Fangyi/Ambrish: No. - Ambrish: The output of channel 1 is used as the input to channel 2. - Discussion: Fangyi/Ambrish and Walter continued to disagree with certain assumptions and interpretations in each other's arguments and counter examples with respect to BIRD 166. Arpad asked if Fangyi had an update on his proposal, which last week's straw poll had shown support for pursuing. Arpad asked if Fangyi's proposal could be made to address legacy IBIS models, perhaps by way of the multiple-calls-to-Init() suggestion Arpad had made. Fangyi said his proposal did not address legacy models. Fangyi and Walter said they had thought about the multiple-calls-to-Init() approach and didn't think it could solve the legacy model issue. Walter asserted that BIRD 166 and Fangyi's proposal were orthogonal in the sense that BIRD 166 changed a flow that Fangyi's BIRD didn't address. Arpad noted that Fangyi had presented an example in which BIRD 166 made things worse. Walter said he felt that example was specious and based on incorrect assumptions. Arpad asked the various parties to work out these differences of opinion, and said he hoped it was just a miscommunication. Walter suggested there were actual disagreements about the underlying math. - Michael M.: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Radek to send BIRD 158.6 draft 2 to Mike L. for posting to the ATM work archive. ------------- Next meeting: 11 July 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives